工具買完了、帳號開了、大家也開始用了，真正困難的問題，通常是這時候才開始。
昨天提到，總經理問 AI 導入的成效，我準備了很多數字，卻沒有回答到他真正想知道的事：開發有沒有變快？維運負擔有沒有降低？
回頭看採購這件事，我們很容易把問題問得非常仔細。
買幾個帳號？給哪些人用？選哪一種方案？權限怎麼管理？公司資料可不可以放進去？需不需要安排教育訓練？
這些都需要處理。但就算每一題都有答案，還是可能漏掉最重要的一題：買完之後，我們期待哪一件工作變得不一樣？
如果這一題沒有先講清楚，後面的報告自然就會往容易取得的數字靠。帳號開好了、同仁有登入、使用量增加了。每個數字都是真的，卻還是接不上總經理的問題。
所以今天先把工具放旁邊。開始開發以前，我想先留下三個答案：要解決什麼問題？期待什麼成果？如何衡量？ 最後再補上，誰負責追這件事。
買到使用權、有人使用、能穩定完成工作，以及工作真的改善，中間還有幾步。Claude 能交出文件與程式，不代表接手的人就少了工作。
例如維護既有 .NET 系統時，假設工程師與 Reviewer 經常花時間重找狀態轉換的規則、例外與測試，那要改善的可能是「反覆重建背景」。這是規劃示例，不是已量測的公司成果。若卡在規則沒人確認，請 Claude 多寫一些程式，只會多出一份待確認的修改。
所以我會先留下三個答案：
| 開始前要問 | 用這類修改來說 |
|---|---|
| 要解決什麼問題？ | 接手者反覆找規則、問背景，才敢繼續工作 |
| 期待什麼成果？ | 修改附上規則來源與測試依據，減少重新理解與返工 |
| 如何衡量？ | 比較同類工作從理解到驗收的投入，品質條件不降低 |
這裡要量的是整件工作。AI 生成得快，卻讓人核對更久，未必省力；PR 等了一天，也不代表人工作了一天。人工投入與經過時間要分開留下，才有辦法回看。
再指定一位追結果的人，約好何時回來看：資料有沒有留下？品質有人確認嗎？要繼續、修正還是暫停？不用等所有制度完善，但這次嘗試要有人接著追。
回到規格交接這件事，我會先分清楚卡住的原因，再決定工具。
如果規則還沒有人決定，先找能確認的人。AI 可以整理選項與待確認問題，但不能替團隊決定哪個版本有效、誰接受變更。
如果規則已固定，例如偵測檔案變更、通知指定窗口或檢查必填欄位，先用程式自動化。這些事情能明確判斷，沒有必要每次請模型重新理解。
如果需要閱讀分散的文件、整理版本差異或提出可能的影響範圍，再考慮讓 AI 協助。交回來的摘要要附來源，並安排接手者核對，才知道它有沒有真的減少理解工作。
所以，同一次規格交接，可以由程式送通知、AI 整理差異，再由負責人確認規則與影響。
要決定的是 AI 適合接哪一段，以及核對它的代價是否值得。
先選有人能核對結果的小範圍工作開始，實際用過，再把接手與返工的問題帶回 Retro。我從自己最熟悉的開發工作開始嘗試。把規格交給 Claude Code，請它協助實作與補測試，很快就有了可以檢查的產物。
但流程、人與工具，不會在第一天就配合得剛剛好。產出變快之後，哪些地方省力、哪些地方反而更難接手，要真的用過才看得見。
不過，開發協作不只交程式，還要交代需求、設計與測試依據。程式有了可檢查的版本之後，相關文件怎麼讓下一個人看懂，也是交付的一部分。這些使用經驗，成了我們在 Retro 裡回頭討論的材料。
有了使用經驗，我們透過 Retro 把遇到的問題帶回來。其中一個回饋很具體：文件產得多、散落各處，難以完整 Review；審查也缺少共同標準，容易流於形式。
原本期待 AI 協助整理背景，交接時卻還得處理找文件、辨認版本與確認審查範圍的問題。從這些回饋整理出來，接手者需要回答的是：哪版有效？改了什麼？我要確認什麼？ 這三問是對問題的整理，不是同事的逐字引言。
依 Retro 問題整理的情境示意，非現場截圖；文件已有產出，不代表交接已完成。
這時候再請 Claude 多寫一份文件，未必能讓工作往下走。開發、測試與產品角色可能各看不同材料；大家都有東西看，仍不一定對著同一版規則。
Retro 的作用就具體了：從這次卡住的交接，回頭找哪個環節要改。流程上，版本與差異怎麼傳達？人這邊，誰要確認什麼、有沒有時間，也能不能說出用了沒有比較省力？工具這邊，能否協助整理差異，而不是繼續增加散落的文件？
以規格變動為例，先處理的是「改了，接手者卻不知道」。我整理導入經驗時留下的一項做法，是 commit hook 自動提醒加上 Teams 通知：把規格變動的提醒接進工作流程，讓接手者有機會回來核對。
接著才是「找到之後，看得懂嗎」。Sprint SPEC 用來整理當期規格，ADR 留下決策脈絡，Spec Viewer 協助閱讀。這幾項各處理不同缺口，不能只把工具裝齊，就當成交接已改善。
目前能核對的是作者導入簡報中的實施敘述，尚未找到可公開的實際通知或變更摘要。因此這裡展示做法，不虛構訊息欄位，也不宣稱已減少補問或返工。若下一輪要檢查效果，就要把通知、對應版本與接手者後續補問一起留下來。
通知也有它的界線。送到了，不代表接手者已理解，更不代表他接受了規則。如果後面仍要重新問背景，就得繼續查交付內容與責任，不能只看通知有沒有發出去。
規格交接示意。通知、理解與接受，是需要分別確認的事。
其他卡點也各有對應的調整。以下依導入經驗整理，並非每項措施都由同一次 Retro 觸發。
| 卡住的地方 | 已做：導入整理中的實施記錄 | 規劃／仍待驗證 |
|---|---|---|
| 規格變動，接手者不易掌握 | 規格變動提醒；補上當期規格與決策脈絡；提供閱讀入口 | 是否減少補問與返工，還缺完整對照 |
| 多人平行開發，介面與理解容易分岔 | 先對齊 OpenAPI；調整 Jira 流程，透過 Retro 對齊規格目的 | Review 分流與共同完成條件需要持續驗證 |
| 角色與責任不清，對 AI 有疑慮 | 把角色問題納入 Retro 與分工討論 | 陪跑、分享與角色補位持續安排，未宣稱疑慮已消失 |
**流程、人與工具需要一起調整。**不能只要求大家更熟悉工具，卻讓其他部分維持原樣。
找到盲點、選了調整，還只是這一輪的決定。把回看放進固定節奏，下一輪才有機會核對：上次選的問題還在嗎？改動有沒有幫接手的人往下做？
我會把回看安排在固定節奏裡，例如隨 Sprint 一起。下一次拿出上次的決定，核對做了什麼，再決定保留、修正或停止。
如果現在開始一個小範圍試用，我會先填這張卡，並把它帶到下一次回顧：
要改善的工作：規格變更後的開發／測試交接
目前卡點：接手者不易知道版本與差異
這次試改：版本通知＋變更摘要；摘要可由 AI 協助
負責與接受：誰推進調整，誰確認規則與影響
觀察方式：補問次數、人工核對時間、版本誤解造成的返工
比較條件：先約定期間與同類任務；品質門檻不降低
回看時間：填下一次 Retro 日期
下一輪決定：依觀察保留、修正或停止，記下理由與負責人
這是從經驗整理出的試用與回顧格式，不是已完成的績效表。每輪挑少量做得完的改動，有資料就核對，資料不足就補觀察，才有機會知道下一步值得改什麼。
參考資料：
iThome鐵人賽
看影片追技術